UCCE Scripting Example

Posted on by Admin

Related Post

UCCE Scripting Example

OK, so UCCE scripts work differently from UCCX scripts. Because I personally hate reading manuals and configuration guides, i always like to learn new things hands on and supplement that with theoretical knowledge. This approach has always served me well, ever since I entered into IT.  So let me do some explanation around UCCE scripting using an example.


 Now UCCE, uses the ICM script editor to create the scripts. The way calls get delivered to UCCE once they arrive at CUCM, is by means the a Peripheral GW. This gets triggered through a CTI Route Point which is registered with the IP address of the PG; 10.1.2.1 (see below).
 

 

 
As can be seen in Fig.1 , TEST Q (x12345) is a registered CTI RP, registered on 10.1.2.1, which is our Peripheral Gateway (PG). This CTI RP uses extension 12345.

 The way these CTI RP’s get registered is through adding them to CUCM and associating them with the JTAPI application user ID that is defined on CUCM and that is defined on UCCE during installation.

When I said that UCCE scripts are different from UCCX scripts, I did not only mean the way the are built, but also the functions that they can perform. In terms of functions, UCCE scripts are still dependent on IPIVR’s (that are nothing more than old school UCCX aef scripts). It means that basic tasks such a playing prompts and digit selection are carried out by an IPIVR (UCCE does this by invoking an external script).
 
In terms of UCCE script layout, they are resemble call flows and are therefore very easy to follow, much easier than UCCX scripts.


 
UCCE Routing scripts (contrary to administrative scripts) are mainly triggered by dialed number (DN) and sometimes by means of Caller entered digits.
Figure 2 show an example UCCE script. As you can see it is very modular and easy to follow a certain call flow.

Figure 2 – Example ICM Script


Fig.2 show and example script that calls for external scripts, does some digit collection and then sends the call to the relevant Skill Group (a.k.a. agent Queue). Let look at this in a bit more detail. In this script first the Translation route to VRU is been carried out, which pretty much dictates which UCCX server will be used to invoke the external script. Let’s enhance the next steps:

Figure 3 – Caller entered digits/Digit collection




A Run external script node is added, which is called “Collect Digits” and points to CollectDigits.aef (figure 4)

Figure 4  – Collect Digits external script.


This external script, plays a prompt, defines input length and values. Pretty standard stuff.

Figure 5 – Digit Collection aef


After this, the aef script sets the  Enterprise Call Info and passes it on to ICM

Figure 6 – Set Enterprise Call Info

Back to Fig. 2. After the digit collection (CED), the call continues (via case 1), to another external script, which does an external DB look up (Service Tier Look up). It matches the ANI and verifies which service tier is associated with it. 

Figure 7 – SQL DB query


It then also passes the value back to ICM by means of Enterprise call info.

Figure 8 – Enterprise  Call Info for service Tier



So this Service Tier  value obtained from the SQL DB, it is used to determined is the caller is part of “GOLD” or not (Fig.9)

Figure 9 – ICM IF LOGIC  node



based on the Tier entitlement of the caller, the call gets delivered to a gold Tier service queue or silver Tier service queue.
I have already mentioned that there are few ways to trigger a script, one of which is the Dialed Number/Script Selector. Figure 10 shows and example of this. It shows a DN node with extension 7706, and if we look at the properties of this node, there is one target Dial number being matched being matched.

This means that if an incoming call (into the PG) to this DN  is made, i.e. the value is TRUE (tick box) is made and the call flow will go right to “SET VARIABLE”. The Dialed Numbers are items that can be added through the configuration manager on the AW  (administrative workstation).
Routing script execution and selection

Before the ICM/UCCE software execute a routing script it classifies each call into call type that you have defined. ICM then determines which script to execute, based on the call type schedule. (Compare this to UCCX where a trigger is defined, based on its CTI RP, which has a script statically assigned to it). ICM can use Dialed Number (DN), Calling Line ID (CLID) or Caller-Entered digits (CED) as the call qualifier (see fig.12).
Finally I want to give an example of A DN and an associated script.  For example Figure 11.  Take a test DN, that is matched when 5417641400 is being dialed (remember there needs to be a CTI Route point on CUCM to trigger this).
Fig. 11 – Script selector/Dialed number page
 
So the dialed number named ” CVP_PIM.5417641499 ” has 5417641400 associated with it.  If I now go to the “dialed Number mapping” Tab, as depicted in figure 12. This is where you point that dialed number to a certain script, in this case “PreSaleCT”. 
Fig. 12 – Dialed number Mapping
 
 
The actual association between a call type and a script, can ONLY be configured through the script editor.  I will explain more about this in my next post:  
ICM dailled number and script association.